Veeam Staged Restore - это поэтапное восстановление виртуальных машин и возможность выполнения сканирования антивирусом данных резервных копий при восстановлении. Таги:
В конце января компания Veeam, известная своим лучшим решением для резервного копирования виртуальных машин Veeam Backup and Replication (о последней версии мы писали вот тут), провела ренейминг и коррекцию позиционирования своих бесплатных продуктов.
Теперь все бесплатное называется Community Edition, при этом продукты с этим неймингом будут предоставлять больше возможностей, чем их Free Edition предшественники.
Соответственно, вот какие продукты выпускаются в бесплатном издании Community Edition:
1. Veeam Backup for Microsoft Office 365 Community Edition.
Ограничения бесплатной версии:
Максимальное число пользователей Exchange: 10.
Максимальное число пользователей OneDrive for business: 10.
Максимальный объем защищаемых данных SharePoint: 1 ТБ.
Поддержка вида Best effort.
2. Veeam Backup & Replication Community Edition.
Ограничения бесплатной версии:
Доступны все функции издания Standard.
Резервное копирование ограничено 10 объектами (физические или виртуальные машины).
Вот какие возможности предоставляет Veeam B&R Community Edition по сравнению с коммерческими версиями:
3. Veeam ONE Community Edition.
Ограничения бесплатной версии (их стало меньше, чем в прошлой бесплатной версии):
Только один экземпляр Veeam B&R (платный или community edition) может быть добавлен.
Нет возможностей Application level monitoring.
Нет функции email customization.
Отсутствует часть функционала отчетности.
Некоторые прочие ограничения.
Veeam ONE еще в процессе ребрендинга, поэтому называется пока Free Edition, скоро это поменяется.
О новых возможностях Veeam Backup and Replication 9.5 Update 4 мы уже детально писали вот тут, а сегодня расскажем о новых фичах последних двух решений.
1. Veeam Availability for AWS.
Этот продукт позволяет защитить ваши виртуальные машины в публичном облаке Amazon от случайного удаления, вредоносной активности или различного рода сбоев за счет резервного копирования и восстановления инстансов EC2. Это решение было анонсировано еще на VeeamON 2017, но только сейчас вышла его финальная версия.
Оно комбинирует в себе возможности купленной Veeam компании N2WS cloud-native backup and recovery для рабочих нагрузок AWS с возможностью консолидации резервных копий в центральном репозитории Veeam.
Продукт предоставляет следующие возможности:
Безагентная защита виртуальных машин на AWS средствами снапшотов (для целей мгновенного восстановления). Делается это на базе сервиса Amazon EBS.
Возможность долговременного хранения бэкапов в облаке Amazon S3 или онпремизной инфраструктуре компании. Это экономит затраты на хранение до 40%.
Быстрое восстановление из резервных копий в облаке, включая такие технологии как instant recovery, восстановление напрямую в онпремизный датацентр или в другое облако. Возможность восстановления в другой аккаунт.
Расширенный поиск по инфраструктуре хранения бэкапов.
Восстановление баз данных на определенный момент времени, а также послеаварийное восстановление Amazon RDS, Redshift и DynamoDB в другой регион AWS или аккаунт другого пользователя.
Узнать больше о решении Veeam Availability for AWS можно на этой странице.
2. Veeam Availability Console v3.
Это уже третья версия консоли Availability Console для сервис-провайдеров (напомним, что сама по себе она бесплатна). О ней мы детально писали вот тут. Это комплекс интегрированных средств для сервис-провайдеров и больших компаний, которые позволяют организовать инфраструктуру BaaS (Backup-as-a-Service) для гибридной среды предприятия (внутренние инфраструктуры + облачные).
Давайте посмотрим на новые возможности сервис-провайдеров, которые приходят вместе с Veeam Backup and Replication 9.5 Update 4:
Интеграция для пользователей Veeam Cloud Connect Replication и VMware vCloud Director, что позволяет построить единую платформу управления облачной платформы и предлагать комплексное DRaaS-решение в рамках единого пространства сети, оборудования и средств самообслуживания.
Cloud Gateway Pools для Veeam Cloud Connect Backup and Replication - теперь с помощью этого функционала можно развернуть внутренние пулы IP-адресов клиентов, которые подключаются к вашей сети через MPLS или VPLS соединения. Это улучшает изоляцию между клиентами и упрощает развертывание больших инфраструктур в облаках.
Расширенная поддержка резервного копирования на базе агентов. Теперь средства Veeam Agents поддерживают несколько одновременных задач резервного копирования, что позволяет еще более гибко управлять ими со стороны облачного провайдера.
Также теперь для сервис-провайдеров доступны следующие новые возможности решений для резервного копирования и мониторинга виртуальных сред Veeam:
Более подробно о Veeam Availability Console можно узнать на этой странице.
Обязательно посмотрите большой анонс этих продуктов, в котором принял участие основатель компании Ратмир Тимашев:
В этой статье мы остановимся только на лидирующем в отрасли продукте Veeam Backup and Replication 9.5 Update 4, который уже сейчас доступен для скачивания:
Давайте посмотрим, какие интересные новые возможности появились в Veeam B&R 9.5 Update 4:
0. Поддержка vSphere 6.7 Update1.
Долгожданная поддержка последней версии платформы vSphere 6.7 Update 1, а также решений vCloud Director 9.5 и платформы Windows Server 2019 (включая Hyper-V 2019, Active Directory 2019, Exchange 2019 и SharePoint 2019).
1. Veeam Cloud Tier.
В новом релизе появилась нативная интеграция с облачными объектными хранилищами, которые можно использовать для долговременного хранения бэкапов в рамках концепции Scale-out Backup Repository. При этом оперативные резервные копии можно оставить на ярусе Performance Tier:
Теперь бэкапы можно передавать в облачное хранилище Amazon S3, Azure Blob Storage, IBM Cloud Object Storage, любое S3-совместимое хранилище или в другой датацентр для целей архивного хранения и/или катастрофоустойчивости.
Кстати, эта схема не требует наличия каких-то виртуальных модулей от вендоров облачных платформ, что позволяет не завязывать эту схему на одно конкретное облако.
2. Veeam Cloud Mobility.
Эти возможности позволяют восстановить резервные копии виртуальных машин, хранящиеся в репозиториях Veeam (в том числе, от Veeam Agent для Windows и Linux), на любую из облачных платформ в производственную среду. На данный момент поддерживаются платформы AWS, Azure и Azure Stack, а также любые онпремизные бэкапы:
Для облака AWS EC2 происходит автоматическая конверсия UEFI на BIOS для виртуальных машин.
3. Veeam DataLabs.
Данные функции Veeam B&R позволяют тестировать различные рабочие нагрузки, валидировать апдейты и патчи, проверять на наличие уязвимостей и соответствие политикам предприятия, а также убеждаться в общей восстановимости резервных копий.
Здесь Veeam B&R 9.5 Update 4 предоставляет следующие функции:
On-Demand Sandbox - виртуальная песочница для тестирования восстановленных резервных копий.
SureBackup и SureReplica - возможность удостовериться в работоспособности восстановления бэкапов и реплик.
Staged Restore (об этой возможности мы писали вот тут) - позволяет уменьшить время на просмотр и отсеивание чувствительных данных и убрать персональную информацию при восстановлении резервной копии (в частности, об уволенных сотрудниках). Это позволяет соблюсти требования GDPR и не попасть на штраф.
Secure Restore (об этой возможности мы писали вот тут) - возможность сканирования восстановленных резервных копий с помощью антивирусного программного обеспечения, чтобы устранить угрозы перед вводом восстановленных бэкапов в производственную среду.
4. Veeam Intelligent Diagnostics.
Эти возможности позволяют установить на серверы Veeam B&R агенты Veeam ONE, которые анализируют логи процесса бэкапа и самого решения для резервного копирования, что позволяет идентифицировать и решить проблемы самостоятельно, без обращения в техническую поддержку.
Сигнатуры с описанием известных проблем загружаются из базы знаний Veeam.
5. Прочие улучшения.
Полный список улучшений нового Veeam B&R приведен в документе What's New, а мы особенно отметим следующие:
Портал самообслуживания для ролевой модели доступа vSphere RBAC на базе Enterprise Manager.
Теперь новый VCG позволяет получить ответы на следующие вопросы:
Какой дисковый массив поддерживает технологию VVols?
Какую версию ESXi поддерживает тот или иной вендор оборудования?
Какая есть сертификация VASA?
Какие возможности VVols поддерживает устройство?
Какие проблемы или ограничения имее реализация VASA Provider на устройстве?
Кликнув на производителя (Partner Name), вы увидите какие типы VASA Provider он поддерживает и на каких моделях дисковых массивов.
Также, выбрав нужную вам фичу VVols, например, VVols Storage Replication, вы можете вывести всех производителей, кто ее поддерживает:
Раскрыв категорию Partner Name для нужного производителя, вы увидите какие версии ESXi какие функции поддерживают:
Обратите внимание, что справа в таблице есть ссылка "VASA Provider Download", которая позволяет вам загрузить актуальную версию компонента-провайдера интерфейса VASA.
Также есть еще один полезный раздел, который открывается по клику на "Click here for more Details":
Тут уже можно найти детальную информацию о поддерживаемых протоколах, статьях базы знаний (KB), версии VASA provider и VASA VVol Spec, а также многое другое.
В конце декабря ушедшего года компания VMware выпустила обновление своего консольного фреймворка для управления виртуальной инфраструктурой - PowerCLI 11.1.0. Напомним, что прошлая мажорная версия (PowerCLI 11.0) была выпущена в октябре прошлого года.
Давайте посмотрим, что нового в этом обновлении:
1. Улучшения Site Recovery Manager Module.
Теперь средствами модуля VMware.VimAutomation.SRM для PowerCLI обеспечивается мультиплатформенная поддержка в плане управления инфраструктурой Site Recovery Manager. Этот модуль можно использовать с PowerShell Core на платформах MacOS и Linux. Он стал одним из первых специализированных модулей, сконвертированных на другие платформы.
В модуле Storage (VMware.VimAutomation.Storage) было сделано несколько исправлений ошибок и улучшений. Теперь командлет Get-VsanDisk выводит диск vSAN, где находится Witness Component. Также для командлета Start-SpbmReplicationTestFailover больше не нужен параметр VvolId.
Скачать PowerCLI 11.1 можно по этой ссылке. Напомним, что традиционно PowerCLI обновляется следующей командой:
Весной 2018 года Selectel запустил услугу резервного копирования для Облака на базе VMware посредством Veeam® Backup&Replication™ (далее VBR). К реализации проекта мы подошли основательно, спланировали и выполнили следующий перечень работ:
Изучение документации и лучших практик по продуктам Veeam
Разработку архитектуры VBR уровня сервис-провайдера
Еще 8 лет назад мы писали о кэшировании в решении StarWind Virtual SAN, которое является лучшим на сегодняшний день программным средством создания отказоустойчивых хранилищ для виртуальных машин. У кэширования на запись write-back есть недостаток - возможность потери данных в случае отключения электропитания. Поэтому сегодня мы расскажем о том, что такое новый Log-structured Write Cache (LWC), и для чего он нужен...
Не все из вас знают, что в начале этого года компания VMware запустила облачный DR-сервис по обеспечению катастрофоустойчивости виртуальной инфраструктуры в облаке - VMware Site Recovery. Это так называемое DRaaS для публичного облака VMware Cloud on AWS (VMC), которое позволяет организовать disaster recovery (DR) инфраструктуру без капитальных затрат на организацию резервной площадки, покупку оборудования и т.п. для бизнес-критичных приложений - можно просто взять ее в аренду и платить по времени использования.
Это Disaster Recovery as-a-Service (DRaaS) решение на базе публичного облака дает следующие преимущества:
Возможность быстро развернуть резервное окружение для онпремизной инфраструктуры vSphere в облаке.
Функции vSphere Replication, обеспечивающие, в случае массового сбоя в датацентре, потерю данных в объеме всего RPO=5 минут.
Единую консоль Site Recovery Manager (SRM), которая позволяет оркестрировать весь процесс восстановления после аварии.
Учитывая возможности решения Site Recovery, можно выделить 4 основных сценария использования данной технологии:
Обеспечение DR-инфраструктуры для приложений, которые ранее не были защищены.
Возможность репликации данных из облака в другой регион AWS или другую онпремизную инфраструктуру.
Сервис Site Recovery работает с любым решением для организации хранилищ, особенно эффективен он будет вкупе с решением vSAN, которое, в свою очередь, может быть построено на различных аппаратных платформах, например, Dell-EMC VxRail.
Кстати, на VMworld 2018 компания VMware объявила, что теперь в рамках одного кластера SDDC на площадке можно защищать до 1000 виртуальных машин, что в 2 раза больше, чем раньше:
Кроме того, теперь добавлена возможность (пока в режиме превью) реплицировать несколько онпремизных площадок в одну облачную VMware Cloud on AWS DR.
Некоторое время назад мы писали о продуктах и технологиях, анонсированных на конференции VMworld Europe 2018 (часть 1 и часть 2), а сегодня поговорим о еще одной технологии, объявленной в рамках мероприятия - VMware vSAN Native Data Protection. О ней в своей статье рассказал Viktor van den Berg.
Данная технология будет представлять собой репликацию данных виртуальных машин на уровне хранилищ на базе снапшотов (а также будет доступна локально в рамках хранилища) в целях создания резервных копий ВМ. Работать этот механизм будет в соответствии с текущей механикой политик Storage Policy Based Management (SPBM).
Использовать технологию vSAN Native Data Protection можно для трех сценариев:
Защита локальных виртуальных машин без использования снапшотов vSphere.
Репликация данных машин на стороннее хранилище NFS.
Репликация данных машин на другую площадку (другой кластер vSAN) под управлением того же (или другого) сервера vCenter.
Технология vSAN Local Data Protection будет использовать механизм native vSAN snapshots, который почти не оказывает влияние на производительность ВМ (поскольку работает на уровне хранилища). Также будут поддерживаться консистентные с точки зрения приложений снапшоты, которые будут использовать скрипты Microsoft VSS / VMware Tools для "подморозки" приложений.
Вот так эта настройка будет выглядеть в мастере конфигурации политики хранилищ для ВМ:
Как мы видим, можно установить частоту создания снапшотов (по сути, требования RPO). Далее идет настройка про то, с какой периодичностью делать application consistent снапшоты. Ну и в конце - число хранимых снапшотов.
Некоторые снапшотоы можно будет хранить в течение долгого периода времени в архивных целях:
Также расписание снапшотирования и откидывания на NFS-хранилище будет представлено в таблице:
Сточки зрения восстановления машин из локальных снапшотов, будет использоваться технология Linked Clone, с помощью которой процесс поднятия ВМ будет занимать около одной минуты. Восстановление полностью независимой ВМ займет существенно больше времени (в зависимости от объема хранилища). При восстановлении ВМ можно выбрать кластер, куда восстанавливать, а также VM Network.
Также в процессе работы vSAN Native Data Protection можно просматривать информацию о ее состоянии в целом:
И для виртуальных машин:
Также будет несколько интересных моментов:
Пока не будет интеграции vSAN Native Data Protection и SRM.
В будущем планируется создание резервных копий с помощью снапшотов для групп ВМ (consistency groups), если они, например, располагаются на разных хранилищах.
Минимально RPO можно указать как 5 минут.
Для обеспечения консистентности бэкапов на уровне приложений можно будет использовать собственные скрипты подготовки и возобновления приложения, а также Microsoft VSS.
Технология будет интегрирована со сторонними решениями для резервного копирования и фреймворком VADP.
Репликация на удаленное хранилище также будет использовать снапшоты в своей основе.
Без application consistent снапшотов (только crash consistent) хранилище будет снапшотиться мгновенно.
Будет поддерживаться репликация как между разными кластерами, так и между разными vCenter.
В качестве архивного хранилища будет поддерживаться пока только NFS, но потом можно будет использовать и облачный сторадж Amazon S3.
Нативные снапшоты будут дедуплицироваться и сжиматься при передаче.
Доступность технологии vSAN Native Data Protection ожидается в первом квартале 2019 года, а пока вы можете запросить доступ к vSAN Beta, где эта технология уже имеется.
Совсем недавно стало известно о трех очень серьезных багах в платформе VMware vSphere, которые затронули, как платформу vSphere 5.x/6.x, так и средство создания отказоустойчивых хранилищ для виртуальных машин VMware vSAN 6.6/6.7.
1. Повреждение данных виртуальных дисков снапшотов формата SEsparse.
Начиная с VMware ESXi 5.5, диски стапшотов виртуальных машин стали создаваться в формате SEsparse. Такой диск создается в ESXi 5.5 если диск машины более 2 ТБ, а начиная с ESXi 6.0 / VMFS6 - он используется для снапшотов всех машин. Так что под угрозой практически все виртуальные машины со снапшотами. А ведь снапшоты используются всеми ВМ, для которых применяется резервное копирование через механизм vSphere API for Data Protection (например, с помощью продукта Veeam Backup and Replication).
Ну а суть бага заключается в том, что блоки данных могут оказаться поврежденными, что приводит к неконсистентности файлов для приложений (например, баз данных), а также иногда к невозможности загрузки виртуальной машины!
Баг и возможные способы решения описаны в KB 59216. В vSphere 6.7 Update 1 баг уже пофикшен. Для остального есть следующие апдейты:
Для ESXi 5.5 обновления нет, но вы можете отключить функцию "IO coalescing" для формата дисков SEsparse. Делается это следующей командой:
esxcli system settings advanced set -i 0 -o /COW/COWEnableIOCoalescing
2. Проблема консистентности виртуальных дисков машин на платформе vSAN 6.6.
Аналогично багу из прошлого пункта, здесь может произойти неприятность с целостностью данных виртуальных машин, которые работают в кластере хранилищ VMware vSAN 6.6. Это может случиться в следующих обстоятельствах:
vSAN начинает процесс ресинхронизации
В этот момент вы расширяете диск VMDK виртуальной машины
vSAN снова начинает ресинхронизировать уже расширенный диск виртуальной машины
Проблема описана в KB 58715. В этом случае вы сможете только восстановить консистентность виртуальных машин, но сами данные приложений вы уже не вернете.
3. Получение доступа root к хосту ESXi из виртуальной машины.
Если вы используете виртуальные машины с драйвером сетевого адаптера vmxnet3 (у него был еще один отдельный баг), то для непропатченных хостов есть возможность получения доступа root к шеллу ESXi из виртуальной машины.
Кстати, это было публично показано впервые:
#GeekPwn2018 Chaitin Tech security researcher f1yyy has escaped VMware EXSi and got root shell on the host for the first time in the world. After demonstrating it at GeekPwn 2018, f1yyy received the Best of Tech Award and was selected to the GeekPwn Hall of Fame.@GeekPwnpic.twitter.com/2Y2kYKaw4d
Информация об этой уязвимости опубликована в VMware advisory VMSA-2018-0027. Там же есть и названия необходимых вам патчей (обратите внимание, что багу подвержены также и платформы Workstation / Fusion).
На днях компания StarWind Software выпустила серьезное обновление своего флагманского продукта для создания отказоустойчивых программных хранилищ под виртуализацию StarWind Virtual SAN V8. Напомним, что это решение на сегодняшний день является лидером отрасли и, на наш взгляд, является самым удобным и мощным средством создания реплицируемых хранилищ для виртуальных машин.
Давайте посмотрим, что нового появилось в Virtual SAN V8 (build 12585) от 25 октября:
1. Виртуальная ленточная библиотека VTL и функции облачной репликации (Cloud Replication)
Добавлена поддержка ленточных устройств LTO8.
Добавлены новые команды PowerShell для управления устройствами VTL и настройками Cloud Replication. Вы можете посмотреть примеры использования по адресу C:\Program Files\StarWind Software\StarWind\StarWindX\Samples\powershell\.
2. Демо-версия NVMf Target.
Простой NVMf Target можно создать в демонстрационных целях. Существующий NVMf initiator можно теперь использовать для соединения с этим таргетом.
Простые устройства RAM Disk и Flat Storage теперь поддерживаются. Например, рекомендуется использовать сетевые адаптеры Mellanox RDMA-enabled с последними драйверами от производителя.
Также можно использовать любые другие адаптеры, которые реализуют слой NetworkDirect API.
Учитывайте, что процесс установки StarWind VSAN перезаписывает конфигурационный файл NVMf Target (nvmf.conf). Если во время установки уже есть файл nvmf.conf, он будет сохранен как nvmf.conf.bak.
Для новой версии запросите новый лицензионный ключ (даже если сейчас NVMf работает) - как для издания Free, так и для триальной лицензии.
3. Улучшения синхронной репликации.
Исправлена проблема, когда процессор (CPU) узла хранения мог оказаться загружен на 100% CPU. Это происходило потому, что в некоторых случаях транспорт канала синхронизации мог загружать одно ядро CPU полностью. Если число каналов синхронизации совпадало с числом ядер CPU, сервис переставал отвечать.
Не все администраторы платформы виртуализации VMware vSphere знают, что такое Network I/O Control (NIOC). Причина проста - функции механизма регулирования полосы пропускания NIOC для различных видов трафика на стороне vSphere Distributed Switch (vDS) есть только в издании vSphere Enterprise Plus, которое, как правило, приобретают большие и средние компании.
Давайте посмотрим, что такое NIOC и разберем эту функциональность на примерах. Прежде всего, функция NIOC появилась тогда, когда с появлением сетей 10G стало понятно, что можно делать сетевую инфраструктуру на хостах ESXi с небольшим числом сетевых адаптеров, обладающих высокой пропускной способностью. Но в этих условиях также стало ясно, что сетевой трафик, идущий по таким сетям, надо в рамках того же 10G-канала как-то разграничивать.
NIOC позволяет системным и сетевым администраторам настраивать приоритизацию следующих видов трафика для пула сетевых адаптеров хостов ESXi:
Fault tolerance traffic
iSCSI traffic
vMotion traffic
Management traffic
vSphere Replication traffic
Network file system (NFS) traffic
Virtual machine (VM) traffic
User-defined traffic
Механизм NIOC появился еще в 2010 году в VMware vSphere 4.1, и с тех пор был очень сильно доработан (сейчас в vSphere 6.7 Update 1 доступна третья версия NIOC v3).
В интерфейсе HTML5-клиента vSphere Client эти настройки выглядят так (новый клиент полностью поддерживает рабочие процессы NIOC):
В vSphere Web Client вы можете увидеть эти настройки по адресу vDS > Manage > Resource Allocation > System traffic:
Механизм NIOC включен по умолчанию (для vSphere 6.0 и выше), но для типов трафика не заданы никакие ограничения (Limit) и резервации (Reservation) - только приоритеты между типами трафика (Shares). Работают эти 3 техники регулирования типа трафика так же, как и аналогичные механизмы для хранилищ или вычислительных ресурсов:
Reservation - гарантирует тому или иному типу трафика пропускную способность канала в Мбит/с. Важно помнить, что эта ширина канала резервируется, но в случае ее простоя ее смогут использовать другие типы системного трафика. Между тем, простой канала зарезервированного системного трафика не дает возможность распределить полосу на виртуальные машины. В любом случае, Reservation (если он вам очень нужен) нужно выставлять таким, чтобы обеспечить только минимальные запросы сервиса для его функционирования, а не средние и максимальные.
Limit - ограничивает сверху используемый канал для выбранного типа трафика.
Shares - с помощью чисел приоритета (от 1 до 100) позволяет выделить группы которые будут получать больше или меньше пропускной способности канала (например, если одна группа имеет 100, а другая 50 - то первая будет получать в два раза больше на фоне распределения всего трафика адаптеров по группам). Механизм этот начинает распределять канал после раздачи всех заданных резерваций.
Есть еще один нюанс - только 75% совокупной ширины канала на хосте ESXi может быть зарезервировано (а если говорить точнее - от адаптера с самой низкой пропускной способностью в этой группе на хосте). Остальные 25% остаются на всякий случай (например, компенсация всплесков управляющего трафика). Все, что не распределено с помощью Reservation, будет регулироваться средствами механизма Shares.
Для изменения резервации, лимита или shares категорий системного трафика надо открыть настройки конкретного типа трафика:
Для удобства Shares можно указывать не цифрами, а выбрать из комбо-бокса один из вариантов - Low (25), Normal (50) и High (100). В этом случае цифры для Shares автоматически подберутся (они указаны в скобках), чтобы составлять верные соотношения согласно выставленным приоритетам. После выставления этих параметров они будут применены на всех физических адаптерах хостов ESXi, подключенных к распределенному коммутатору vDS на сервере vCenter.
Когда вы задаете Reservation, максимальная пропускная способность для данного типа трафика будет равна этому значению, умноженному на число физических адаптеров на хостах, выделенных для этого типа трафика.
NIOC v3 также позволяет сконфигурировать резервации как на уровне отдельных виртуальных машин (в свойствах адаптера), так и создавать собственные пользовательские пулы (User-Defined Network Resource Pools), которые являются подмножеством корневого пула
Virtual machine (VM) traffic.
Для User-Defined Network Resource Pools выставление лимитов и Shares не предусмотрено - только Reservation.
В свойствах адаптера vNIC резервации на уровне отдельной ВМ можно выставить в ее настройках (это только гарантированная полоса, но машина может использовать и больше, если есть доступные ресурсы):
Если вы выставляете Reservation для адаптеров виртуальных машин, то их суммарная резервация не может быть больше, чем резервация для VM system traffic на этом хосте:
Если нужно настроить сетевые пулы ресурсов для групп виртуальных машин, то нужно создать новый пул в Web Client:
А потом указать резервацию для него:
Потом этот пул нужно указать при настройке распределенной группы портов на распределенном коммутаторе vDS:
Ну а к этой распределенной группе портов нужно уже подключить виртуальные машины, которые на всех получат эту резервацию.
При этом если вы задали резервацию 1 Мбит/с, а физических адаптеров на хосте ESXi у вас 5, то такая распределенная группа портов получит до 5 Мбит/с на свои виртуальные машины.
В итоге картина выглядит подобным образом:
Когда вы создадите новый пул в разделе Network Resource Pools, вы сможете посмотреть список виртуальных машин в нем на вкладке Virtual Machines:
Ну и напоследок отметим, что лимиты для сетевых адаптеров машин должны согласовываться с лимитами политики traffic shaping для распределенной группы портов, куда они воткнуты. Например, если для адаптера выставлен лимит 200 Мбит/с, а для всей порт-группы на vDS только 100 Мбит/с, то эффективным ограничением будет именно 100 Мбит/с.
На прошлой неделе компания Veeam в Праге собирала участников сообщества Veeam Vanguards 2018, где мы пили чешское и катались по Влтаве. Но самым интересным было не это, а рассказы о перспективах компании, ее новых продуктах и технологиях, о которых мы расскажем в ближайшем будущем.
Один из самых ожидаемых релизов - это Veeam Backup and Replication 9.5 Update 4, который, скорее всего, будет официально поддерживать резервное копирование виртуальных машин на недавно вышедшей новой версии платформы VMware vSphere 6.7 Update 1 (хотя и на данный момент фактически он на ней прекрасно работает, но нужно кое-что сделать).
В новой версии VBR будет много всего полезного, но давайте остановимся на двух возможностях. Первая - это функция Staged Restore, которая позволяет проводить манипуляции с данными внутри бэкапов с помощью скриптов перед их реальным восстановлением в производственную среду.
Главное назначение этой возможности - соблюдения комплаенса GDPR (если вы работаете с данными европейцев), который закрепляет, в частности, за бывшим работником организации право на удаление персональной информации о нем, которая хранится, как минимум, в Active Directory. Поэтому с помощью сценариев можно удалить аккаунт бывшего пользователя из AD и, например, его почтовый ящик из Exchange, чтобы не нарваться на нарушение и штраф.
Схема выглядит так - администратор восстанавливает резервную копию в полностью изолированное окружение, с помощью сценария PowerShell удаляет из машины требуемые данные, после чего она переходит в производственную среду:
В принципе, вы можете создать список действующих сотрудников в текстовом документе и удалять из бэкапа тех, кто ему не соответствует. Но для этого надо быть знакомым с PowerShell. Ну а примеры подобных сценариев вы скоро найдете в репозитории Veeam на GitHub (VeeamHub).
Вторая интересная фича Update 4 - это возможность проверки антивирусом резервной копии перед восстановлением (как раз на стадии Staged Restore), чтобы она не заразила производственную среду:
Причем поддерживаются не только самые распространенные антивирусы, но и с помощью сценариев вы сможете интегрировать любой антивирус, который поддерживает запуск из командной строки. В этом случае виртуальная машина и ее данные как бы помещаются на карантин (Antivirus Quarantine) и далее, пролечившись, они могут быть восстановлены в продакшен.
Зачем это нужно, если у вас уже есть антивирус внутри ВМ? Очень просто - есть атаки, называемые Zero-day, то есть, например, ваши данные были заражены вирусом, о котором еще не знает ваш антивирус. В этом случае в бэкап этот вирус попадет, ну а при восстановлении он заразит вашу виртуальную машину, вызвав, например, полное блокирование ее работы.
Процесс Secure Restore позволяет защититься от этого вида уязвимостей:
Более подробно о новых возможностях Veeam Backup and Replication 9.5 Update 4 мы расскажем в ближайшем будущем - когда он выйдет.
Недавно компания VMware объявила о выпуске обновленной версии решения vCloud Availability Cloud-to-Cloud Disaster Recovery 1.5, которое предназначено для репликации и восстановления виртуальной инфраструктуры в одном из облаков сервис-провайдеров (между датацентрами, в каждом из которых работает vCloud Director).
Напомним, что это решение дополняет семейство продуктов VMware vCloud Availability for vCloud Director, которое предназначено для сервис-провайдеров и выполняет функции обеспечения доступности виртуальных машин в их публичных облаках.
vCloud Availability Cloud-to-Cloud DR - это часть сервисов VMware Cloud Provider Platform, обеспечивающих функционирование публичных облаков. При этом данное решение подключается как плагин для vCloud Director и работает между облаками различной природы (онпремизными и публичными), предоставляя репликацию и восстановление виртуальных машин и сервисов vApp между различными экземплярами vCloud Director в разных датацентрах.
Кстати, первая версия этого решения по отзывам сократила время ручных операций по обслуживанию и диагностике служб репликации на 72%. Давайте посмотрим, что нового появилось в Cloud-to-Cloud DR версии 1.5.
Улучшения произошли в 5 ключевых областях:
1. Интегрированный пользовательский интерфейс в vCloud Director.
Сервис-провайдеры, использующие vCloud Director 9.1 и более поздние версии продукта, получили обновленный интерфейс (для предыдущих версий останется старый). Кроме того, клиенты сервис-провайдеров получили возможность включить функции Disaster Recovery и зайти в vCloud Director прямо из тулбара.
Также обновился и API до версии 1.5 (он позволяет интегрировать функции vCloud Availability Cloud-to-Cloud DR в пользовательские порталы). API теперь позволяет управлять такими продуктами и процессами, как: Replication manager, рабочие процессы репликации vApp, мониторинг состояния системы, первоначальная конфигурация репликации (создание туннеля, DNS, конфигурации точек репликации и т.п.), а также управление системой на уровне всей площадки.
Помимо этого, теперь для Cloud-to-Cloud DR обеспечена сквозная аутентификация из vCloud Director, что очень удобно для пользователей.
2. Улучшения юзабилити и рабочих процессов.
В новой версии Cloud-to-Cloud DR появилась возможность управления политиками, которые позволяют задать RPO ну уровне клиента, что дает возможность обеспечить различным клиентам разный уровень соответствия политикам RPO (а для последней версии vSphere можно обеспечить RPO=5 минут). Также можно установить максимальное число снапшотов и максимальное число репликаций на клиента.
Одна из новых удобных возможностей - это комплексные фильтры, которыми можно вывести виртуальные машины и объекты vApp, к которым далее можно применить некоторые действия (например, создать снапшоты или запустить восстановление).
3. Улучшения масштабируемости инфраструктуры.
Теперь можно использовать до 300 активных репликаций для одного большого узла vCloud Availability Replicator, около 100 клиентов с активными репликациями, до 7 экземпляров vCloud Availability Replicator на один экземпляр vCloud Availability Cloud-to-Cloud и до 2 ТБ объема защищаемых VMDK-дисков. С точки зрения операций, их может быть где-то до 120 штук одновременно, а всего тестировалось до 3000 активных операций для более чем 100 клиентов (программного ограничения нет).
4. Плагин Orchestration plugin для создания собственных рабочих процессов.
Через некоторое время станет доступен отдельный плагин, который будет работать под vRealize Orchestrator и будет позволять конструировать такие рабочие процессы, как, например, построение инвентори или сбор и обработка данных от экземпляров vCloud Availability vApp Replication Manager. Рабочий процесс можно сделать в vRealize Orchestrator Client, после чего импортировать его в vCloud Director и далее исполнять их там.
5. Функции улучшения ежедневной эксплуатации для администраторов.
vCloud Availability Cloud-to-Cloud 1.5 будет иметь плагин для vRealize Operations 6.6.1 и более поздних версий (будет доступен несколько позже), который будет предоставлять информацию о компонентах и их активностях, инвентори, общему состоянию, сработавших алармах, доступной емкости, статусу репликации и прочему. Сервис-провайдеры теперь смогут показывать клиентам расширенные отчеты, в которых будет информация о соблюдении оговоренных KPI и SLA.
Трудно представить ситуацию, в который бизнес не заботился бы о сохранности данных, критичных для него приложений. Рано или поздно любая компания, использующая современные IT-технологии, приходит к пониманию, что даже незначительный простой в работе может повлечь крупные финансовые издержки, а потеря информации – так и вовсе стать причиной гибели бизнеса.
Для предотвращения остановок работы сервисов используются средства для повышения доступности и отказоустойчивости, дублируются узлы в IT-инфраструктуре либо сервис передается на подготовленную и изначально сконфигурированную на отработку отказов площадку IaaS-провайдеров. Но для сохранности данных используются системы для их резервного копирования и восстановления.
Резервное копирование – гарант надежности данных бизнеса
Вспоминая высказывание о том, что люди делятся на два типа: на тех, кто не делает бэкап, и на тех, кто уже делает, хочется отметить, что это не интернет-шутка, а горькая правда жизни. За этой фразой скрывается боль и отчаяние людей, слишком поздно осознавших необходимость резервного копирования.
Некоторые до сих пор ошибочно полагают, что повышение уровня отказоустойчивости и доступности является средством защиты информации и развернутые на многочисленных кластерных нодах дублирующие друг друга сервисы спасут их от, скажем, работы вирусов-шифровальщиков, от повреждений баз данных, моментально среплицируемых по всему кластеру, и от человека, случайно или злонамеренно нанесшего ущерб целостности данных. Поэтому покупка системы резервирования данных воспринимается не как неизбежные траты, а как шаг по защите инвестиций в информационную составляющую вашего бизнеса.
Системы резервного копирования необходимы вне зависимости от модели инфраструктуры, будь то on-premises – когда все системы сосредоточены на локальных площадках компании, cloud – когда задача отдана в том или ином виде в зону ответственности облачного провайдера, или гибридная. Любые данные требуют защиты, и с ростом перехода компаний на организацию инфраструктуры по модели IaaS данный вопрос вставал все острее. Камнем преткновения в отношениях IaaS-провайдеров и их клиентов были вопросы резервирования данных, сроки их хранения, расписание и сама возможность делать резервные копии. Если даже такая возможность предоставлялась, то о тонкостях настройки речи не было, все «кастомные» изменения осуществлялись посредством контакта со службой поддержки. Но сейчас резервное копирование данных в облаке как услугу предлагает все большее число облачных провайдеров, и это стало стандартом.
Место Veeam Backup & Replication на рынке ПО резервного копирования
Одним из лидеров в индустрии резервного копирования является компания Veeam. Она прочно укрепилась в лидирующей пятерке магического квадрата Gartner, а по версии IDC будет занимать первое место на рынке. И не удивительно – продукт Veeam Backup & Replication зарекомендовал себя как надежное средство резервного копирования и восстановления данных с богатым функционалом и простым, интуитивно понятным интерфейсом.
Self-Service Portal – инструмент для самостоятельного управления резервным копированием облачной инфраструктуры
Начиная с версии 9.0 пользователям стал доступен Veeam Backup Enterprise Manager, созданный для централизации управления серверами Veeam с возможностью делегирования прав управления резервным копированием. Последняя функция позволила облачным провайдерам предоставлять своим клиентам Self-Service Portal для самостоятельного управления резервным копированием своей облачной инфраструктуры. Никаких отличий от решения для on-premises нет: пользователь получает весь функционал продукта с полной интеграцией с предоставленной облачной инфраструктурой.
Представляем нового партнера VM Guru — компанию Selectel, надежного провайдера IT-инфраструктуры в России. Selectel предоставляет серверы любых конфигураций, сдает в аренду места под размещение оборудования и предлагает облачные услуги. По итогам 2017 года Selectel занимает 4-ю позицию в рейтинге CNews «Крупнейшие поставщики услуг ЦОД в России 2017». В активе компании 6 современных дата-центров...
Таги: Selectel, IaaS, Cloud, VMware, vCloud Director
Cormac Hogan, специалист по отказоустойчивым серверным хранилищам на базе хостов VMware vSAN, написал интересный пост о "растянутых кластерах" (vSAN Stretched Clusters). Это кластеры, которые образуют единое пространство хранения между двумя географически разделенными площадками, в котором продолжают работать различные механизмы обеспечения доступности виртуальной инфраструктуры, например, VMware HA (он восстанавливает отдельные ВМ в рамках площадок, а также всю площадку целиком в случае ее сбоя).
Если вы используете виртуальные ПК на базе полных клонов с инфраструктуре VMware Horizon View, то вы можете исполнять их на растянутом кластере в конфигурации Active/Passive в рамках одного View Pod (набора серверов Connection Server):
Это именно Active/Passive конфигурация, которая поддерживает пользовательские соединения только на одной площадке, вторая находится в резерве, а вся инфраструктура десктопов управляется одним набором серверов View Pod, размещенном на основном сайте:
Такая архитектура позволяет поддерживать единое пространство хранения и репликации в рамках растянутого кластера, реплицируемого на уровне дисковых объектов vSAN между площадками, а не виртуальных машин, как в случае с vSphere Replication.
В случае сбоя нужно будет только запустить серверы View Connection Servers, которые будут управлять виртуальными машинами на резервной площадке, находящимися в актуальном состоянии с точки зрения дисков. Обо всем этом отлично написано в Appendix H соответствующего раздела документации.
Надо отметить, что архитектура Active/Active (когда десктопы активно работают на обеих площадках) в решении Horizon View не поддерживается для растянутых кластеров. Причина в том, что группа серверов Connection Servers в рамках одного сайта (Pod) должна иметь отличное соединение по сети LAN, чему нет гарантий в среде растянутого кластера, когда они разместятся на обеих площадках.
При этом ничего не мешает вам использовать Active/Active-конфигурацию не для растянутого кластера, а для двух Pods с разными кластерами vSAN на каждой из площадок в рамках архитектуры Cloud Pod Architecture (CPA).
Ну а если вы используете non-persistent виртуальные десктопы и связанные клоны (Linked Clones) или мгновенные клоны (Instant Clones), то рекомендация VMware тут та же самая - не использовать растянутый кластер vSAN. Потому что, в отличие от полных клонов, данные дисковых объектов могут создаваться и уничтожаться на лету в больших объемах, что пока еще не поддерживается для единого пространства хранения vSAN.
Вместо этого нужно создавать View Pod на каждой из площадок и поддерживать свой кластер vSAN на уровне каждого сайта, как показано на картинке выше.
Ну и еще момент - решение VMware AppVolumes также не поддерживается в растянутых кластерах VMware vSAN.
Таги: VMware, vSAN, Stretched, DR, HA, View, Horizon
Вебинар пройдет в эту среду, 8 августа в 12-00 по московскому времени. Регистрация тут.
На вебинаре представители M1Cloud и Veeam Software расскажут о практических подходах к обеспечению высокой доступности критичных данных и максимальной надежности работы приложений в облаке для реализации проектов средних и крупных предприятий.
Вводное слово: Чем мы обеспечиваем повышенную надежность облачной инфраструктуры M1Cloud для бесперебойной работы бизнес-критичных приложений. (Владимир Денеко, Архитектор отдела архитектуры клиентских решений Stack Group / M1Cloud)
Послеаварийное восстановление как услуга (Disaster Recovery as a service) на базе Veeam Cloud Connect в инфраструктуре облачного сервис-провайдера. Практика применения. (Владимир Денеко, Архитектор отдела архитектуры клиентских решений Stack Group / M1Cloud; Ирина Ленцнер, Инженер направления «Cloud», Veeam Software)
Сверхвысокая доступность данных при резервном копировании, в том числе для удаленных пользователей, с помощью сервиса Veeam Agent под управлением сервис-провайдера. (Ирина Ленцнер, Инженер направления «Cloud», Veeam Software)
Резервное копирование как сервис под управлением облачного сервис-провайдера на инфраструктуре Заказчика и в облаке на базе Veeam Backup & Replication. Особенности применения для быстрого и надежного резервного копирования и восстановления. (Владимир Денеко, Архитектор отдела архитектуры клиентских решений Stack Group / M1Cloud)
Object Storage: сценарии практического применения. S3, как способ сокращения издержек для архивного хранения данных в облаке. (Владимир Денеко, Архитектор отдела архитектуры клиентских решений Stack Group / M1Cloud)
Перспективы развития и ожидаемый функционал технологий резервного копирования Veeam. (Ирина Ленцнер, Инженер направления «Cloud», Veeam Software)
Заключительная часть и ответы на вопросы (специалисты Stack Group и Veeam Software).
Для кого
Данный вебинар предназначен для руководителей ИТ отделов, руководителей направлений облачной инфраструктуры, системных администраторов, ведущих ИТ-специалистов, архитекторов и ведущих инженеров, ответственных за ИТ-инфраструктуру компании.
Содержание докладов актуально всем ИТ специалистам, кому необходимо обеспечить максимальную надежность данных и стабильную работу корпоративных приложений в облачной среде.
Также, вебинар будет полезен тем, кто еще только планирует использовать облачную инфраструктуру и сервисы в дополнение к имеющейся инфраструктуре.
Мы много пишем о технологии Virtual Volumes (VVols) - например, тут, тут и тут. Она позволяет более гибко подходить к хранению объектов виртуальных машин за счет передачи некоторых функций работы с их данными на сторону хранилищ.
Несмотря на то, что структура хранения виртуальных машин на базе технологии VVols со стороны устройства хранения выглядит по-другому, нежели на классических томах VMFS, резервное копирование для таких ВМ традиционными средствами вполне поддерживается. Об этом мы уже рассказывали тут и вот тут, а сегодня немного дополним эти посты.
Для ПО резервного копирования тома виртуальные машины на томах VVols выглядят аналогично таковым на томах VMFS, поэтому ни схема, ни средства резервного копирования в инфраструктуре VVols не изменяются:
Резервное копирование делается через механизм vSphere APIs for Data Protection (VADP), который создает снапшот на хранилище, чтобы после его создания ПО для бэкапа могло забрать диски с данными ВМ. Отличие тут в том, что в этой схеме снапшот ВМ делает программное обеспечение дискового массива, на сторону которого передаются операции по работе со снапшотами и другие функции.
Кстати, интересная штука - стандартно для виртуальной машины в VMware vSphere можно сделать до 32 снапшотов, хотя VMware рекомендует делать их не более 2-3 в одной цепочке, так как большее количество может привести к различного рода проблемам. А вот с аппаратными снапшотами на томах VVols можно сделать 32 снапшота, и это никаких проблем не повлечет.
На массивах с поддержкой VVols есть поддержка операций "consolidate" и "revert" для снапшотов. В среде VVols они работают по-другому: там есть базовый VMDK, который всегда остается таковым, и куда идет запись, а также вместо записи изменений в redo log там есть read-only файлы снапшотов, которые не подцепляются в зависимую цепочку. При откате снапшота с базовым VMDK никаких длительных последовательных операций не производится (в отличие от VMFS), соответственно все это делать можно безопасно (подробнее - тут).
Также важно помнить, что использование Change Block Tracking (CBT) и vMotion для виртуальных машин на томах VVols может привести к порче данных (подробнее об этом тут). Эта проблема уже решена, но ее исправления будут доступны в следующих релизах vSphere 6.0, 6.5 и 6.7, а пока отключайте DRS для кластеров с виртуальными машинами на томах VVols.
На момент написания статьи VVols поддерживается для работы в трех режимах резервного копирования:
Резервное копирование за счет монтирования виртуальных дисков (Hot Add backup) - в этом случае к одной ВМ монтируется диск VMDK другой ВМ и происходит его резервное копирование
Резервное копирование по сети передачи данных (NBD backup) - это обычное резервное копирование ВМ по сети Ethernet, когда снимается снапшот ВМ (команды отдаются хостом ESXi), основной диск передается на бэкап таргет, а потом снапшот применяется к основному диску ("склеивается" с ним) и машина продолжает работать как раньше.
Защищенное резервное копирование по Ethernet (NBDSSL) - то же самое, что и NBD backup, только с использованием SSL-шифрования при соединении через TCP/IP.
А вот метод без использования сети Ethernet (SAN-to-SAN backup) по-прежнему не поддерживается. Это происходит потому, что для в традиционной инфраструктуре VMFS есть виртуальный хост backup proxy, который говорит виртуальному модулю резервного копирования, какие блоки нужно читать по сети SAN. В среде VVols через VASA API компонент VASA provider на стороне физического сервера или дискового массива пока не может построить физический SAN-путь от хоста ESXi с томом VVols.
VASA provider нуждается в защите (если он реализован в виде виртуальной машины), так как он содержит в себе структуру томов VVols (и маппинги машин к устройствам), и если этот компонент будет потерян, то вы полностью потеряете управление над хранилищами (запущенные машины при этом еще будут работать).
Надо сказать, что вендоры решений с поддержкой VVols, как правило, сами реализуют отказо- и катастрофоустойчивость своих VP (а также их синхронизацию), но необходимо помнить, что это критически важный компонент, и неплохо бы делать его резервное копирование. Помните, что механизм vSphere HA в данном случае вам не помощник - он предназначен для других задач.
Собственно, практически все решения для резервного копирования виртуальных машин на платформе VMware vSphere на сегодняшний день поддерживают VVols:
Не так давно мы писали о том, что большинство вендоров решений для резервного копирования не сделали обновления своих продуктов для поддержки VMware vSphere 6.7. Сегодня компания Veeam восполнила этот пробел со своей стороны и выпустила апдейт Veeam Backup Replication 9.5 Update 3a, который полноценно поддерживает все возможности последней версии платформы виртуализации от VMware.
Давайте посмотрим на полный список новых возможностей этого обновления:
Поддержка VMware vSphere 6.7.
Предварительная поддержка VMware vSphere 6.5 Update 2 (будет выпущено еще одно обновление, когда VMware пофиксит баг).
Поддержка гостевых ОС Microsoft Windows 10 April 2018 Update и Microsoft Windows Server 1803 в виртуальных машинах, а также систем Hyper-V на базе этой ОС. Также поддерживается и Microsoft System Center Virtual Machine Manager 1801.
Улучшения производительности в режимах Direct Storage Access (DirectSAN) и Virtual Appliance (Hot Add).
Сохранение Linux SUID и SGID при операциях "Copy To". Также появилась поддержка томов Btrfs размещенных на томе LVM.
Задачи резервного копирования Storage snapshot-only для vCloud Director работают для всех поддерживаемых хранилищ (ранее было доступно только для NetApp).
Улучшения и исправления ошибок для служб Veeam Cloud Connect (подробнее - тут).
Исправления ошибок.
Полный список всех нововведений Veeam Backup Replication 9.5 Update 3a приведен в Release Notes. Скачать его можно по этой ссылке. Инструкции по обновлению приведены тут.
В конце апреля этого года компания StarWind выпустила обновление лучшего на рынке решения для создания программных iSCSI-хранилищ под виртуализацию - StarWind Virtual SAN. В конце апреля было выпущено большое обновление Virtual SAN v8, а в середине мая был выпущен еще один небольшой апдейт.
Давайте посмотрим, что нового появилось в StarWind Virtual SAN v8 build 12146 и 12166:
Для модуля Cloud Replication появилась поддержка Backblaze B2 Cloud Storage.
Для синхронной репликации и режима обслуживания (maintenance mode) события, описанные в Event Log, стали более детализированными. Вот примеры:
(id 809) Underlying device response time is longer than expected.
(id 824) Partner "%s" request response time is longer than expected.
(id 825) Request execution time is longer than expected.
(id 821) Maintenance mode is turned ON.
(id 822) Maintenance mode is turned OFF.
Несколько изменено поведение кластера - теперь при ручном отключении двух партнерских HA-устройств на сервере оставшийся узел выпадает в состояние "not synchronized". Также если выпадает HA-устройство, а затем Witness-узел, то при возвращении Wintness-узла в онлайн - работоспособность кластера автоматически восстанавливается.
Теперь отсутствует интервал в 30 секунд между отправкой email-нотификаций, также можно поменять SMTP-порт.
Если хранилище создается на устройстве, которое некорректно сообщает о размере физического сектора, StarWind все равно позволяет его создать, но с предупреждением.
Для управления модулем VTL появилась функциональность StarWindX PowerShell. В составе продукта идут вот эти примеры:
Добавлен пример PowerShell-сценария для управления трехузловым HA-кластером на базе LSFS:
\StarWindX\Samples\powershell\CreateHA_3_LSFS.ps1
Для LSFS была исправлена проблема на устройствах pre-V8R6 (при заполненности данными более 1,2 ТБ могла произойти потеря данных при рестарте сервиса). Были исправлены и некоторые проблемы апгрейда LSFS с релиза V8R5. Также было улучшено поведение LSFS при высоких нагрузках (изменена процедура дефрагментации).
В Management Console была добавлена поддержка новой версии продукта StarWind VSA 2.0.
Было сделано множество исправлений ошибок с HA-устройствами, снапшотами и хранилищами.
Очень рекомендуем текущим пользователям StarWind Virtual SAN v8 накатить это обновление (вот инструкция, как это сделать). Ну а тем, кто еще не развертывал StarWind в своей инфраструктуре - рекомендуем попробовать этот продукт бесплатно. Более подробно о решениях StarWind Software можно почитать в Resource Library.
Во время большой серии весенних релизов, в рамках которой VMware выпустила обновление платформы виртуализации vSphere 6.7 и других продуктов, была также анонсирована и новая версия решения для обеспечения катастрофоустойчивости виртуальной инфраструктуры - VMware Site Recovery Manager 8.1.
Давайте посмотрим, что нового появилось в VMware SRM 8.1:
1. Улучшенный интерфейс на базе HTML5.
Теперь интерфейс управления решением SRM и репликацией построен на базе фреймворка Clarity и технологии HTML5 - это значит, что все работает быстро, а сам интерфейс удобен и приятно выглядит.
2. Переработанные рабочие процессы.
Теперь в SRM рабочие процессы сделаны более гибко и удобно. Например, при настройке защиты виртуальной машины можно добавить ее в существующий план восстановления (Recovery plan) или сразу же создать новый:
3. Гибкость при соединении площадок.
Теперь в SRM 8.1 отсутствует требование по идентичности версий VMware vCenter на обеих площадках. Это значит, что обновления на уровне сайтов вы можете проводить независимо. SRM 8.1 и vSphere Replication 8.1 поддерживают любую комбинацию из vCenter 6.0 Update 3, vCenter 6.5 и vCenter 6.7.
Это дает возможность обновить vCenter, не затрагивая при этом конфигурацию VMware SRM. Кроме того, теперь поддерживается и облачная инфраструктура VMware Cloud on AWS.
4. Упрощенный путь апгрейда SRM.
Теперь SRM поддерживает не только апгрейд с прошлой версии (SRM 8.0), но и прямое обновлений с версий SRM 6.5.
Это позволяет выполнять меньше операций при обновлении, а также не рисковать нарушить конфигурацию при выполнении многошаговых апгрейдов.
5. Утилита по сохранению и загрузке конфигураций Configuration Import/Export Tool.
Эта утилита командной строки, появившаяся впервые в этой версии, позволяет сохранить или накатить конфигурацию SRM. Ее давно ждали, теперь она позволяет не только делать резервные копии сложнейших конфигураций, но и реализовывать миграции, например, на другую СУБД.
Вот список того, что может быть экспортировано и импортировано в инфраструктуру SRM:
Protection Groups
Recovery Plans
Приоритетная группировка ВМ
Взаимосвязи ВМ
Callouts
Кастомизация настроек IP
Маппинги сетей, папок, пулов ресурсов и политик хранилищ
Правила маппинга IP-подсетей
Информация о ВМ-плейсхолдерах
Расширенные настройки (Advanced settings)
Локальный и удаленные адреса площадок
Объекты Array Managers с информацией об SRA-адаптерах
6. Поддержка большего числа Protection Groups.
Теперь защищаемых групп может быть 500 вместо 250 в прошлой версии. Это сделано для Enterprise-пользователей, которым нужно создавать отдельную Protection Group для отдельного приложения, а таких приложений в датацентре может быть очень много.
7. Поддержка виртуальных машин, защищенных Fault Tolerance.
Эту возможность давно ждали. Теперь можно защищать ВМ с включенной технологией непрерывной доступности Fault Tolerance. Однако тут есть несколько ограничений:
Поддерживается только репликация на уровне дискового массива.
Обе FT-машины (Primary и Secondary) должны быть в одной группе array consistency group.
Машина при сбое восстанавливается без включенной FT (ее придется запускать руками на резервной площадке).
8. Улучшения автоматизации.
В SRM 8.1 появилось два дополнительных API:
Получение и настройка параметров IP-кастомизации.
Добавление и удаление датасторов из групп Array-Based Replication Protection Groups.
9. Миграция на Photon OS.
Виртуальный модуль vSphere Replication 8.1 (VR Appliance) с SLES переехал на Photon OS. Это очередной шаг в сторону унификации инфраструктуры виртуальных модулей.
Загрузить VMware Site Recovery Manager 8.1 можно по этой ссылке. Release Notes доступны тут.
Как вы знаете, совсем недавно компания VMware выпустила обновление платформы виртуализации VMware vSphere 6.7, включая гипервизор ESXi 6.7 и средство управления vCenter Server 6.7. Одной из важных составляющих виртуальной инфраструктуры виртуализации является инфраструктура резервного копирования виртуальных машин. Вряд ли можно себе представить крупную компанию, которая обновляет хосты ESXi 6.0/6.5 на 6.7 и готова остаться без резервного копирования ВМ.
Между тем, с поддержкой новой версии vSphere 6.7, которая вышла 18 апреля, у вендоров решений резервного копирования все весьма плохо. Давайте посмотрим, как именно (об этом рассказал блог tinkertry):
Как мы видим, только Veeam позаботилась о том, чтобы проинформировать своих пользователей о поддержке (а точнее неподдержке) новой версии vSphere 6.7.
При попытке использовать Veeam Backup and Replication 9.5 Update 3 вы получите вот такое сообщение об ошибке:
Error: Object reference not set to an instance of an object
Поэтому придется ждать обновления Update 3a, в котором vSphere 6.7 будет полностью поддерживаться для резервного копирования, репликации и восстановления виртуальных машин. Оно выйдет в самом ближайшем будущем (мы обновим пост).
Еще весной прошлого года мы писали про продукт Veeam Availability Orchestrator, который предназначен для восстановления виртуальной инфраструктуры из реплик Veeam Backup & Replication после аварии или катастрофы на основной площадке предприятия.
По сути, это качественная замена неказистого продукта VMware Site Recovery Manager. Инженеры Veeam хорошо поработали и сделали один из самых интересных и нужных продуктов компании - теперь стратегии Data Protection и Disaster Recovery можно сделать на базе продуктов одного вендора. На днях Veeam Availability Orchestrator стал доступен для загрузки.
Давайте посмотрим на самые интересные возможности этого решения:
Эта функция позволяет создать необходимый набор документации, в которой отражены основные процедуры и схемы восстановления инфраструктуры после крупного сбоя или аварии средствами Veeam. Тут важны вот какие моменты:
Решение содержит 4 полностью кастомизируемых шаблона отчетности для катастрофоустойчивой инфраструктуры в удобном для пользователя формате.
Возможность соответствия требованиям законодательства и комплаенсу в сфере disaster recovery. Также эти отчеты на регулярной основе не стыдно предоставлять директорам C-level (CEO, CIO и т.п.).
Автоматическое обновление документации при внесении изменений в виртуальную инфраструктуру - то есть поддержание актуальности данных в отчетах.
2. Тестирование плана восстановления после сбоев.
Для того, чтобы организация была уверена в том, что в случае форс-мажора можно будет восстановить функционирование ИТ-инфраструктуры, нужно регулярно проводить тестирование восстановления виртуальной инфраструктуры. Здесь важны следующие моменты:
Возможность исполнения ручного и запланированного тестирования с верификацией восстановления работы ИТ-сервисов.
Доступ в реальном времени к отчетам и дэшбордам, предоставляющим информацию о плановой готовности сервисов, исполнении плана тестирования и восстановления.
Регулярное исполнение тестов без влияния на производственную среду, производительность сервисов и пользователей.
3. Исполнение плана аварийного восстановления в случае аварии.
Это, понятное дело, самая важная фича продукта. Она подразумевает как восстановление работоспособности сервисов основного сайта на резервной площадке (failover), так и обратное восстановление виртуальной инфраструктуры на основную площадку (failback).
Здесь есть вот какие особенности:
Верификация восстановления на уровне виртуальных машин, приложений и сервисов - например, для Microsoft Exchange, SQL Server и IIS — при фейловере с заранее определенным порядком запуска сервисов.
Через открытый API процесс восстановления можно интегрировать с другими средствами обеспечения доступности ИТ-инфраструктуры.
Доступ к средствам планирования и исполнения disaster recovery можно регулировать с помощью ролевой модели доступа (role-based access control, RBAC).
Более подробно о функциях Veeam Availability Orchestrator можно прочитать вот тут. Скачать продукт можно по этой ссылке.
В этом материале мы расскажем о технологиях, которые компания NetApp — лидер на рынке систем хранения данных и решений для хранения и управления информацией — использует в своих продуктах. Если вы давно хотели систематизировать знания, но не находили время, мы сделали это за вас. Предлагаем вашему вниманию компактный глоссарий терминов и определений NetApp.
ONTAP и пиво — что общего?
Действительно, что может быть общего между операционной системой для СХД и пивом? Оказывается, существует довольно любопытная история происхождения буквосочетания ONTAP. Насколько она правдива — остается загадкой, но на страницах сообщества NetApp однажды появилось следующее: «ONTAP — это своего рода акроним, который сам по себе не имеет никакого смысла, тогда как название Data ONTAP было вдохновлено пивом. Идея заключается в том, что данные должны течь свободно, точно так же, как пиво из крана на барной стойке. К тому же название характеризует то, что люди думают о данных: они должны быть там и тогда, когда в них возникает необходимость, ведь не зря on tap означает «готовый к немедленному потреблению или использованию», олицетворяя то, что всегда находится под рукой».
На деле же Clustered Data ONTAP (новое название — ONTAP) — это специализированная операционная система для хранения и менеджмента данных, которая обеспечивает отличную функциональность и централизованное управление. Преимущество системы в том, что ее архитектура и единый интерфейс облегчают процесс управления и использования СХД в средах SAN и NAS, существенно снижая затраты.
FlexArray — лучшее средство для упрощения ИТ-операций
FlexArray — технология виртуализации, которая позволяет в качестве бек-энда использовать сторонние СХД и подключать их по протоколу FCP. Иметь родные полки с дисками производства NetApp необязательно, поскольку существует возможность подключения сторонних СХД через FC-фабрики. Ключевой момент — для работы FlexArray используемая СХД должна обязательно присутствовать в матрице совместимости. Читать статью далее->> Таги: IT-Grad, NetApp, Enterprise, Storage
В блоге VCDX133 появился интересный и полезный список основных ключевых моментов в различных аспектах проектирования инфраструктуры VMware vSphere. Он будет полезен архитекторам и системным инженерам, которые планируют внедрение большой инфраструктуры виртуализации и хотят учесть все основные функции платформы, а также избежать проблем в будущем при масштабировании архитектуры.
Кстати, этот список можно использовать как высокоуровневый опросник перед началом фазы проектирования, чтобы выяснить ключевые потребности заказчика и далее превратить это все в техническое задание на базе полученных требований.
Приведем данный список ниже:
Бизнес-задачи и проблемы
Какие основные задачи стоят при внедрении?
Какие проблемы заказчика предполагается решить?
Варианты использования платформы
Какие варианты использования инфраструктуры VMware предполагает сам заказчик?
Требования/Ограничения/Допущения
Каковы основные требования, какие ограничения учесть, о какие допущениях и неочевидных моментах нужно проинформировать заказчика.
Риски
Какие риски внедрения решения (например, простои при миграции) и каковы способы их минимизации? Есть ли специфические задачи, тесты и процедуры, которым нужно следовать в таком случае.
A. Управление виртуальным датацентром
Решения в области логической архитектуры
Общий объем объединяемых в пул ресурсов (вычислительные мощности, сети и хранилища).
Какие сервисы будет предоставлять инфраструктура.
Необходимый уровень доступности для систем управления платформой виртуализации.
Интеграция со сторонними решениями: IT Service Management, Infrastructure Management systems, Enterprise services (DNS, LDAP, NTP, PKI, Syslog, SNMP Traps), сбор данных агентами систем различных вендоров.
Необходимы ли расширенные операции, не предоставляемые из коробки?
Механизмы защиты рабочих нагрузок гипервизора (vMotion, HA и другое).
Механизмы балансировки нагрузки на гипервизор (DRS).
Решения в области физической инфраструктуры
Гипервизор: версии ESXi.
Нужен ли отдельный кластер управления?
Серверы vCenter в режиме Standalone или Linked-Mode?
Версия vCenter Server и тип установки (под Windows или в виде виртуального модуля).
База данных vCenter Server - встроенная или внешняя?
Механизмы защиты vCenter Server.
Дизайн инфраструктуры Platform Services Controller (PSC). Будет ли один домен SSO?
Нужна ли инфраструктура шифрования (PKI)? Какие требования к SSL?
Какие компоненты vSphere будут использоваться?
Нужна ли функциональность Host profiles?
Вопросы управления обновлениями ESXi, версиями VM Hardware и версиями VMware Tools.
Интеграция с антивирусами и решениями vShield/NSX.
Нужен ли пакет vRealize Suite для расширенных операций и управления частным облаком?
Нужен ли продукт vRealize Orchestrator для управления рабочими процессами операций? Нужен ли PowerCLI для сценариев автоматизации?
Нужно ли интегрировать виртуальную инфраструктуру с другими средствами управления (Enterprise Management)?
Automated vendor support mechanisms? How will VMware Skyline be used?
Нужно ли организовывать интеграцию с системами Service Desk или Change Management?
Каковы требования к механизмам vSphere HA и vSphere DRS?
Если будет использоваться HCI (Hyper-Converged Infrastructure), то какие решения будут использоваться для управления, и как это будет совместимо с vSphere?
Вопросы интеграции со службами DNS и NTP.
Ролевая модель доступа (Role Based Access Control) и интеграция с LDAP.
Какой интерфейс vCenter Server будет использоваться для администрирования и ежедневных операций (vSphere Client / Web Client).
Модель лицензирования vCenter.
Вопросы лицензирования стороннего ПО в виртуальных машинах (на хост, на виртуальный процессор vCPU и т.п.).
B. Вычислительные ресурсы
Решения в области логической архитектуры
Традиционная архитектура, технология Server-Side Flash Cache Acceleration, конвергентная или гиперконвергентная инфраструктура (связано с хранилищами).
Минимальное число хостов в кластере.
Тип сайзинга хостов в кластерах: вертикальный (Scale Up) или горизонтальный (Scale Out)?
Гомогенные или гетерогенные узлы?
Число физических процессоров на хост.
Резервирование уровня хостов в рамках доменов отказа (Failure Domains).
Необходимая емкость по CPU.
Необходимая емкость по RAM.
Решения в области физической инфраструктуры
Вендор серверов.
Тип процессоров серверов.
Фичи CPU: VT-x, Hyper-threading, Turbo Boost, включена ли NUMA?
Конфигурация серверного оборудования.
Число сокетов CPU на узел.
Модель процессора, частота и число ядер.
Нужен ли GPU?
Физическое размещение хостов.
Тип размещения: Single Rack или Multi-Rack с шарингом ресурсов?
Требования к доступности кластеров.
Нужно ли обеспечить согласованность доступности хостов с доступностью хранилищ.
Будущее расширение вычислительных ресурсов.
C. Хранилища
Решения в области логической архитектуры
Традиционные хранилища, технология Server-Side Flash Cache Acceleration, конвергентная или гиперконвергентная инфраструктура (связано с вычислительными ресурсами).
Блочные или IP-хранилища?
Средства автоматизированного управления хранилищами.
Допустимо ли использование RDM?
Метод загрузки хоста ESXi - с локального диска (DAS), LUN или PXE.
Толстые или тонкие диски для виртуальных машин?
Необходимые ресурсы хранения.
Репликация хранилищ.
Решения в области физической инфраструктуры
Вендор систем хранения.
Расчет используемой емкости хранилищ с учетом пулов хранения, затрат на репликацию и бэкап. Каковы численные требования к емкости и производительности хранилищ?
Число дисков SSD и HDD в каждой из систем хранения.
Использование дедупликации, сжатия данных, технологии Erasure Coding и Storage APIs. Нужно ли держать процент хранилищ всегда свободным?
Какой активный Working Set (рабочий объем данных) необходим?
Трешхолды для автоматизированного ярусного хранения данных (разнесения по ярусам).
Использование шифрованных дисков и сервер KMS.
Сеть хранения данных и ее организация.
Механизм загрузки хстов ESXi.
Технологии VM DirectPath I/O и SR-IOV.
Число датасторов на кластер.
Будут ли использоваться DRS и SIOC?
Будут ли применяться VMDK shares на уровне виртуальных дисков?
Будет ли использоваться технология VAAI?
Использование VASA и профилей хранилищ (storage profiles).
Будут ли использоваться синхронные или асинхронные DR-решения?
Планирование расширения хранилищ.
D. Сетевая инфраструктура
Решения в области логической архитектуры
Технология Legacy 3-Tier Switch, Collapsed Core или Clos-type Leaf/Spine?
Кластеризованные физические или отдельные коммутаторы EoR/ToR?
Растянутые логические VLAN или на уровне стойки?
Трафик будет функционально разделяться на уровне виртуальных коммутаторов или отдельных VLAN?
Некоторые из вас знают, что VMware больше не является сервис-провайдером публичных облаков со своей собственной железной инфраструктурой (этот бизнес был продан французской OVH), но у нее есть две облачных инициативы с партнерами лидирующих облачных решений - VMware vCloud on AWS и VMware vCloud on Azure.
Блогер Ryan Kelly написал интересный пост, в котором он сравнивает оба решения - и выводы явно не в пользу vCloud on Azure. Давайте посмотрим:
1. Управление.
VMware vCloud on AWS - это полноценный vSphere Client, к которому вы привыкли в вашем датацентре. Все те же средства автоматизации операций и скрипты PowerCLI работают в облаке без необходимости их доработки.
VMware on Azure имеет собственную консоль управления, а также свой API, что потребует адаптации ваших решений и сценариев PowerCLI. Таким образом, вам нужно будет поддерживать 2 набора рабочих процессов, при этом персонал должен иметь два набора умений для этого, что обходится дороже и неудобно.
2. Миграция рабочих нагрузок в облако и обратно.
vMotion между онпремизной инфраструктурой и облаком происходит без изменения IP-адреса, используется растянутый кластер под контролем решения NSX. Серверы управления vCenter объединены режимом Linked Mode.
В облаке vCloud on Azure миграция vMotion не поддерживается, нужно копированием переносить виртуальные машины, а IP-адрес в любом случае поменяется при перенесении ВМ в облако (кстати, обратного пути миграции нет):
3. Стоимость решения.
Для VMware vCloud on AWS используется модель Host-based pricing, то есть покупаете нужное количество хостов, а все остальные лицензии (включая хранилища кластера vSAN) уже включены в цену. На хосте вы можете создать сколько угодно и какие угодно виртуальные машины. Подробности в прайс-листе.
Для vCloud on Azure лицензирование идет по инстансам виртуальных машин, а за хранилище надо платить отдельно. Вот прайс-лист.
4. Катастрофоустойчивость на уровне площадок.
vCloud on AWS обеспечивает полную связность площадок, прозрачную для пользователей. С помощью технологии Host based replication образ ВМ реплицируется между облаком и онпремизным сайтом, шарится общий IP-адрес. В случае сбоя на одной из площадок, для восстановления работоспособности сервиса нужно будет только нажать на кнопку.
При восстановлении машины в облако Azure нужно будет ее как-то скопировать туда, зарегистрировать и сконфигурировать (это будет новая ВМ, у которой другое виртуальное аппаратное обеспечение и драйверы). Также могут возникнуть сложности с бэкапом восстановлением залоченных файлов, которые не берет система резервного копирования на уровне файлов.
Из описанных пунктов может следовать еще несколько неудобств, но даже перечисленных уже достаточно, чтобы не покупать VMware vCloud on Azure. Непонятно пока, кому такая гибридная инфраструктура подойдет - разве что совсем маленьким компаниям, не собирающимся расти.
RSS
